r? @RalfJung

Failed to set assignee to RalfJung: invalid assignee

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

r? @ehuss

Makes sense. It is a new language guarantee, though, so...

@rfcbot fcp merge lang

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

Is there an equivalent statement about alignment that iN and uN have the same alignment in the reference?

Is there an equivalent statement about alignment that iN and uN have the same alignment in the reference?

No. I'd be happy to relax this to just saying that sizes are equal, which is really what I (personally) care about.

TBH I think that both are obvious things to provide. Was just seeing that we have the size equality guarantees for uN & iN (via the table specifying their exact sizes) so this is blatantly obvious for size. Was just thinking that if the alignment equality was worth guaranteeing for usize & isize then it's probably worth doing for the others too.

(I have no strong feelings about the best way to do that. If you wanted to just just make this be size that's fine; if you wanted to just open another PR to also give the alignment guarantee for the specific-sized integer types that'd also be fine.)

Oh I'm totally happy guaranteeing both. From my perspective, more guarantees is always better. But I didn't know if there was some reason that the language might want to keep this option open – maybe theres' some weird opsem thing I don't know about (cc @RalfJung) or some weird architecture on which these two have different alignments. For example, there's that MSVC thing where its allocator allocates 8-byte-aligned values at 4 byte alignment – maybe there's some architecture where LLVM lowers signed values differently than unsigned ones or something weird like that.

If we end up deciding we're okay with alignment, I'd also be happy to update this PR to guarantee alignment equality b/w all uN and iN, not just usize and isize.

No weird opsem thing I am aware of (LLVM doesn't even know the sign of our integers most of the time). But the potential for weird architectures is of course unbounded and that's not my expertise. That said, AFAIK the LLVM data layout string cannot even represent sign-dependent alignment so it seems unlikely that LLVM could work on a target where integers with the same size and different sign have different alignment. Cc @nikic

🔔 This is now entering its final comment period, as per the review above. 🔔

Is there an equivalent statement about alignment that iN and uN have the same alignment in the reference?

I think there should be.

No weird opsem thing I am aware of (LLVM doesn't even know the sign of our integers most of the time). But the potential for weird architectures is of course unbounded and that's not my expertise. That said, AFAIK the LLVM data layout string cannot even represent sign-dependent alignment so it seems unlikely that LLVM could work on a target where integers with the same size and different sign have different alignment. Cc @nikic

Yes, LLVM data layout is sign independent. Technically, Clang could use different alignment based on signedness, in much the same way __int128 and _BitInt(128) have different alignment despite being the same i128 type on the LLVM IR level. I'm not aware of any targets where this would be the case though, and it seems pretty unlikely to me. Platform ABIs are crazy, but not that crazy.

@rfcbot reviewed

god I hope this is not controversial

@rfcbot reviewed

From the lang meeting: please also make another PR to add the ∀N, alignof(iN) == alignof(uN) rule.

(Rather than needing to change this one that's already in FCP.)

Put up #2205 to guarantee ∀N, alignof(iN) == alignof(uN).